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I DENT I F C CAT I ON OF MISS IMG PROPERTIES IN MODEL CHECKING 

FIELD OF THE INVENTION 

The present invention relates generally to design 
automation and verification, and specifically to 
hardware verification of integrated circuit design. 

BACKGROUND OF THE INVENTION 

Hardware verification is currently the bottleneck 
and the most expensive task in the design of a 
semiconductor integrated circuit. Model checking is a 
method of formal verification that is gaining in 
popularity for this purpose. The method is described 
generally by Clarke et al. in. Model Checking (MIT 
Press, 1999), which is incorporated herein by 
reference . 

To perform model checking of the design of a 
device, a verification engineer reads the definition 
and functional specifications of the device and' then, 
based on this information, writes a set of properties 
{(J)} (also known as a specification) that the design is 
expected to fulfill. The properties are written in a 
suitable specification language for expressing temporal 
logic relationships between the inputs and outputs"' "of 
the device. Such languages are commonly based on 
Computation Tree Logic (CTL) . A hardware model M (also 
known as an implementation) of the design, which is 
typically written in a hardware description language, 
such as VHDL or Verilog, is then tested to ascertain 
that the model satisfies all of the properties in the 
set, i.e., that M*=4>, under all possible input 
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sequences. Such testing is a form of reachability 
analysis. 

Model checking is preferably carried out 
automatically by a symbolic model checking program, 
such as SMV, as described, for example, by McMillan in 
Symbolic Model Checking (Kluwer Academic Publishers, 
1993), which is incorporated herein by reference. A 
number of practical model checking tools are available, 
among them RuleBase, developed by IBM, which is 
described by Beer et al. in "RuleBase: an 
Industry-Oriented Formal Verification Tool, " in 
Proceedings of the Design Automation Conference DAC 96 
(Las Vegas, Nevada, 1996) , which is incorporated herein 
by reference. 

As hardware devices grow larger and more complex, 
the set of properties needed for model checking becomes 
unwieldy. The verification engineer has no systematic 
way to be sure of whether the property set is complete, 
in the sense of covering all possible states and 
transitions that may occur in the model. If the 
property set is incomplete, a bug in the design may go 
undetected. The engineer may therefore continue to add 
more and more properties indefinitely, never knowing 
whether the set is yet sufficient or not. 

Coverage metrics have been applied in various 
fields of simulation-based verification in order to 
measure and improve the completeness with which a given 
simulation tool represents the actual behavior of a 
target system. An application of such a metric to 
model checking is described by Hoskote et al . in 
"Coverage Estimation for Symbolic Model Checking, " in 
Proceedings of the Design Automation Conference DAC 99 
(IEEE Computer Society Press, 1999), which is 
IS999-035 2 
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incorporated herein by reference. The authors present 
a method for estimating whether a set of properties is 
sufficient to cover all possible states of a model. 
They note, however, that their method cannot point out 
functionality that may be missing in the model, nor can 
it ensure that all possible paths between the states 
are covered. They indicate that "path coverage would 
be an ideal coverage metric because it can provide 
coverage of actual executions of the circuit over 
time." The authors consider that by comparison with 
state coverage, "path coverage is a much more 
intractable problem." 
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SUMMARY OF THE INVENTION 

It is an object of some aspects of the present 
invention to provide improved methods and systems for 
design verification . 

It is a further object of some aspects of the 
present invention to provide improved methods and 
metrics for analyzing the coverage of a set of 
properties used in model checking, and in particular to 
provide methods for analyzing path coverage. 

In preferred embodiments of the present invention, 
a specification, consisting of properties, is generated 
to verify a given implementation model of a target 
system, and a tableau is constructed corresponding to 
the properties. Such a tableau is defined as a finite 
state machine that satisfies all of the properties in 
the specification. The states and transitions of the 
tableau are compared to those of the model to ascertain 
that there is full correspondence between the possible 
states and transitions of the model and those of the 
tableau. To the extent that there are no substantive 
differences, it is concluded that the set of properties 
fully specifies the model. 

In some preferred embodiments of the present 
invention, the tableau is compared to the model by 
inputting the tableau to a model checking program, such 
as SMV, along with the given model. If for every 
possible combination of inputs, the tableau gives 
exactly the same set of outputs as the model, then the 
specification of the properties is complete. On the 
other hand, if a difference occurs for some input, it 
means that the specified properties are insufficient 
and/or that there is an error in the model. The fact 
that the outputs of the tableau exactly correspond to 
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those of the model indicates that for every reachable 
state of the tableau, there is a corresponding state in 
the model, and for every possible transition in the 
tableau, there is a corresponding transition between 
the corresponding states in the model. It also means 
that there are no excess transitions or spurious 
initial conditions in the tableau that would allow 
transitions to be made among states in a way that would 
not be possible in the model. 

The methods of the present invention thus inform 
the user when the specification of properties is 
complete or, alternatively, provide an indication as to 
where there may be flaws in the correspondence between 
the specification and the model. Such flaws typically 
point either to a state or transition in the tableau 
that is not implemented in the model, thus warning 
either that the specification does not adequately 
constrain the model, or that the model has failed to 
implement a meaningful state or transition of the 
target system. By comparison, the method of Hoskote et 
al. is limited to finding an estimation of state 
coverage, and not transitions or exact state coverage, 

and therefore cannot provide a conclusive indication 

that the set of properties is complete. 

There is therefore provided, in accordance with a 

preferred embodiment of the present invention, a method 

for verification, including: 

providing an implementation model, which defines 

model states of a target system and model transitions 

between the model states; 

providing a specification of the target system, 

including properties that the system is expected to 

obey; 

IS999-035 5 



35277S3 



creating a tableau from the specification, . the 
tableau defining tableau states with tableau 
transitions between the tableau states in accordance 
with the properties; and 

comparing the tableau transitions to the model 
transitions to determine whether a discrepancy exists 
therebetween . 

In a preferred embodiment, creating the tableau 
includes defining a finite state machine using a 
hardware description language, wherein the 

implementation model has model inputs and outputs, and 
wherein defining the finite state machine includes 
describing a virtual device having inputs and outputs 
corresponding to the model inputs and outputs of the 
implementation model. Preferably, comparing the 

transitions includes performing a reachability analysis 
using both the - implementation model and the tableau 
while providing identical inputs to the inputs of both 
the implementation model and the tableau, and verifying 
that the outputs are always identical. Most 
preferably, performing the reachability analysis 
includes comparing the model and the tableau 
automatically using a model checker and providing 
evidence of a tableau transition that is hot 
implemented in the model . 

In another preferred embodiment, comparing the 
tableau transitions includes associating model 
transitions with corresponding tableau transitions, 
wherein associating the transitions includes defining a 
reachable simulation preorder relating the model and 
the tableau. Preferably, associating the transitions 
includes finding a tableau transition that is not 
implemented in the model and, most preferably, deriving 
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an indication, based on the unimplemented transition, 
that the specification is not complete with respect to 
the model. Alternatively or additionally, finding the 
tableau transition that is not implemented in the model 
includes deriving an indication, based on the 
unimplemented transition, that a transition of the 
target system is missing in the model. 

Preferably, the method includes associating model 
states with . corresponding tableau states. Further 
preferably, associating the model states with the 
corresponding tableau states includes finding a tableau 
state that is not implemented in the model and deriving 
an indication, based on the unimplemented state, that 
the specification is not complete with respect to the 
model. Alternatively or additionally, finding the 
tableau state that is not implemented in the model 
includes deriving an indication, based on the 
unimplemented state, that a state of the target system 
is missing in the model. Further alternatively or 
additionally, associating the model states with the 
corresponding tableau states includes finding multiple 
model states corresponding to a single tableau state. 

Preferably, creating the tableau includes creating 
a reduced tableau from which one or more redundant 
states have been eliminated. 

Further preferably, comparing the transitions 
includes verifying that the specification is a complete 
and correct description of the implementation model 
responsive to the comparison. 

There is also provided, in accordance with a 
preferred embodiment of the present invention, a 
verification processor, which is configured to receive 
an implementation model, defining model states of a 
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target- system and model transitions between the model 
states, and to receive a specification of the target 
system, including properties that the system is 
expected to obey, and which is operative to create a 
tableau from the specification, the tableau defining 
tableau states with tableau transitions between the 
tableau states in accordance with the properties, and 
to compare the tableau transitions to the model 
transitions to determine whether a discrepancy exists 
therebetween. Preferably, the processor is operative 
to perform model checking of the implementation model. 

There is further provided, in accordance with a 
preferred embodiment of the present invention, a 
computer software product for verification of a 
specification of a target system, which specification 
includes properties that the system is expected to 
obey, by comparison with an implementation model, which 
defines model states of the target system and model 
transitions between the model states, the product 
including a computer-readable medium having computer 
program instructions recorded therein, which 
instructions, when read by a computer, cause the 
computer to create a tableau from the specification, 
the tableau defining tableau states with tableau 
transitions between the tableau states in accordance 
with the properties, and to compare the tableau 
transitions to the model transitions to determine 
whether a discrepancy exists therebetween. 

Preferably, the program instructions cause the 
computer to compare the tableau with the model by 
running a reachability analysis using both the 
implementation model and the tableau while providing 
identical inputs to the inputs of both the 
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implementation model and the tableau, and verifying 
that the outputs are always identical. Most 
preferably, the reachability analysis is performed 
using an automatic model checker, and the instructions 
cause the computer to verify that the specification is 
a complete description of the implementation model. 

There is additionally provided, in accordance with 
a preferred embodiment of the present invention, a 
method for verification, including: 

providing an implementation model, which defines 
model states of a target system and model transitions 
between the model states; 

providing a specification of the target system, 
including properties that the system is expected to 
obey; 

creating a tableau from the specification, the 
tableau defining tableau states with tableau 
transitions between the tableau states in accordance 
with the properties; and 

comparing the model and the tableau by inputting 
the model and the tableau to an automatic model 
checking program. 

Preferably, comparing the model and the tableau 
includes providing evidence of a transition or state in 
the tableau that is not implemented in the model, most 
preferably in the form of a counter-example indicative 
of the unimplemented transition or state. 

There is moreover provided, in accordance with a 
preferred embodiment of the present invention, model 
checking apparatus, which is configured to receive an 
implementation model, defining model states of a target 
system and model transitions between the model states, 
and to receive a specification of the target system, 
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including properties that the system is expected to 
obey, and which is operative to create a tableau from 
the specification, the tableau defining tableau states 
with tableau transitions between the tableau states in 
accordance with the properties, and to compare the 
tableau to the model by inputting the model and the 
tableau to an automatic model checking program. 

There is furthermore provided, in accordance with 
a preferred embodiment of the present invention, a 
computer software product for verification of a 
specification of a target system, which specification 
includes properties that the system is expected to 
obey, by comparison with an implementation model, which 
defines model states of the target system and model 
transitions between the model states, the product 
including a computer-readable medium having computer 
program instructions recorded therein, which 
instructions, when read by a computer, cause the 
computer to create a tableau from the specification, 
the tableau defining tableau, states with tableau 
transitions between the tableau states in accordance 
with the properties, and to compare the tableau to the 
model by inputting the model and the tableau to an 
automatic model checking program. 

The present invention will be more fully 
understood from the following detailed description of 
the preferred embodiments thereof, taken together with 
the drawings in which: 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a schematic pictorial illustration 
showing a system for model checking, in accordance with 
a preferred embodiment of the present invention; 

Fig. 2 is a block diagram that schematically 
illustrates an implementation model used in model 
checking and a corresponding tableau of properties, in 
accordance with a preferred embodiment of the present 
invention; 

Fig. 3 is a state diagram that schematically 
illustrates a finite state machine corresponding to the 
tableau of Fig. 2, in accordance with a preferred 
embodiment of the present invention; 

Fig. 4 is a flow chart that schematically 
illustrates a method for verifying the correctness of a 
set of properties generated for the purpose of model 
checking, in accordance with a preferred embodiment of 
the present invention; and 

Fig. 5 is a flow chart that schematically 
illustrates another method for verifying the 
correctness of a set of properties generated for the 
purpose of model checking, in accordance with a 
preferred embodiment of the present invention. 
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DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

Fig. 1 is a schematic pictorial illustration of a 
system 20 for model checking, in accordance with a 
preferred embodiment of the present invention. System 
20 typically comprises a verification processor 22, 
typically a general-purpose computer workstation 
running suitable model checking software, such as the 
above-mentioned IBM RuleBase, under the control of a 
verification engineer 24. The system receives a 
hardware implementation model 26 of a target system or 
device 30 in development. Engineer 24 prepares a 
specification of properties 28, for use in model 
checking of model 26. The completeness and correctness 
of the specification are verified by system 20 using 
methods described in detail hereinbelow. 

Reference is now made to Fig. 2, which is a block 
diagram representing a model of a target hardware 
device 40, in this case a simple two-port synchronous 
arbiter, used hereinbelow to exemplify a method for 
verifying property set 28, in accordance with a 
preferred embodiment of the present invention. Device 
40 has two request inputs 42, labeled REQ0 and REQ1, 
and two acknowledge outputs 44, ACK0 and ACK1 . The 
assertion of ACKi is a response to the assertion of 
REQi . Initially, both outputs of the arbiter are 
inactive. At any time, at most one acknowledge output 
may be active. The arbiter grants one of the active 
requests in the next cycle, and uses a round robin 
algorithm in case both request inputs are active. In 
the case of simultaneous assertion (i.e. both requests 
are asserted and were not asserted in the previous 
cycle) , REQ0 has priority in the first simultaneous 
assertion occurrence. In any subsequent occurrence of 

IS999-035 12 . 



35277S3 



simultaneous assertion the priority rotates with 
respect to the previous occurrence. 

An implementation of device 40 in the SMV language 
is presented below in Table I: 



1 ) var 

2) reqO; reql; 

3) assign 

4) ' init(ackO) 

5) init(ackl) 

6) init (robin) 

7) next(ackO) 

8) IreqO 

9) !reql 

10) !ack0&!ackl 

11) 1 

12) esac; 

13) next (ackl) 

14) !reql 

15) IreqO 

16) !ack0&!ackl 

17) 1 

18) esac; 

19) next (robin) : 
20) 



TABLE I 

ackO; ackl; robin : boolean; 

- 0; 
= 0; 
= 0; 

- case 

: 0; - No request results no 

ack 

: 1; - A single request 

:! robin; - Simultaneous requests 

assertions 
:!ack0; - Both requesting, toggle 

ack 



= case 



0; - No request results no 

ack 

1; - A single request 

robin; - Simultaneous assertion 
!ackl; - Both requesting, toggle 
ack 



=if req0&reql& ! ack0& ! ackl then ! robin 
else robin endif; - Two 

simultaneous request 
assertions 
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From the functional specification of arbiter 40 
given above, the following" temporal formulas are 
derived that describe the properties of the device: 

1. The initial state is -iack0 a -iackl. 

2. At all times, mutual exclusion holds, i.e., -.ackO 
v -iackl (property (J>1) - 

3. At all times one of the following properties 
should hold: 

a) No requests followed by no acknowledge 
(property (|)2 ) . 

b) A single request (when the other request is not 
active) is served in the following cycle 
(properties <j>3 and (j)4) . 

c) A request active while the alternate channel is 
being served will be served in the following 

cycle (properties <J>5 and <J)6) . 

d) When a cycle with no active request is followed 
by a cycle with two active requests, the result 
will be as follows - 

• The first such occurrence will result in 
acknowledgment to channel 0 (cj>0) . 

• Each subsequent occurrence will result in 
acknowledgment of the channel that was not 
acknowledged in the previous occurrence (<j)7 
and <|>8) . 

The behavior of the arbiter under these 
conditions (no active request followed by two 
active requests) is governed by the 
non-observable variable "robin," as defined in 
Table I. 
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The above formulas correspond to the properties 
<J>0, (j)l, (|>8 listed symbolically below in Table II, 

which are a complete specification of arbiter 40 
written in the form of .a safety formula \j/ in Universal 
5 Computation Tree Logic (known as ACTL) . ACTL is a 
branching-time temporal logic. It is described in 
detail by Grumberg et al . in "Model Checking and 
Modular Verification," in ACM Transactions on 
Programming Languages and Systems 16(3) (1994), pp. 
10 843-871, which is incorporated herein by reference. As 
the variable "robin" is not observable, it does not 
appear explicitly in the properties in Table II. 

TABLE II 

v|/ = -iack0 a -iacklA 
15 A[ (-ireqO v -ireql v ackO v ackl)W 

(reqO a reql a -nackO a -iackl a AXackO)]A - <t> 0 

AG ( 

(-iack0 v —iackl) a - (j^ 

(-.reqO a -.reql -> AX(->ackO A^ackl) ) a - <j) 2 

20 (reqO a -,reql -> AX ackO) a - 4> 3 

(-ireqO a reql — » AX ackl) a - xjx 4 

(reql a ackO — > AX ackl) a ~ <f>5 

(reqO a ackl AX ackO) a - 4>e 

(reqO a reql A-iackO A-nackl -> AX(ackO — > 

25 A[ (-ireqO v-.reql v ackO v ackl)W 

(reqO a reql A-«ack0 A-iackl a AXackl)]))A -<J> 7 

(reqO a reql A-.ack0 A-.ackl — » AX(ackl — » 

A[ (— .reqO v— .reql v ackO v ackl)W 

(reqO a reql A-iackO A-iackl a AXackO) ] ) ) ) -§ Q 
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This representation uses the temporal operators X 
("next state")/ W ("weak until," i.e., remains true 

until), and G ("globally"), along with the quantifier A 
("for all paths") . It is noted that AG<J> = A[<|>Wfalse] . 

Further details regarding ACTL safety formulas in the 

context of the present invention are presented in 

Appendix A. 

Fig. 3 is a state diagram that, schematically 
illustrates a tableau 50, or state machine, 
corresponding to the properties of the safety formula 
in Table II, in accordance with a preferred embodiment 
of the present invention. The tableau is preferably a 
"reduced tableau, " as defined in Appendix A, which is 
most preferably constructed automatically, using a 
computer program that receives the properties as its 
input and implements the tableau construction algorithm 
listed in the appendix. The tableau is used, as 
described further hereinbelow, to verify that the 
properties completely cover the states and transitions 
of the device model defined in Table I. 

Tableau 50 comprises six state groups 52, 54, 56, 
58, 60 and 62. Each of the groups includes a number of 
states 64 that correspond to a particular output 
condition of device 40, i.e., in groups 52 and 60, ackO 
is asserted; in groups 54 and 62, ackl is asserted; and 
in groups 56 and 58, neither output is asserted (!ack0 
!ackl). In state groups 52, 54 and 56, the 

non-observable variable robin = 0, whereas in groups 
58, 60 and 62, robin =1. As indicated by an arrow 66, 
operation of device 40 begins in group 56, with !ack0, 
!ackl and robin = 0. Transitions from one state to 
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another depend on the choice of inputs, which are 
marked in each state 64. Thus, for example, when reql 
is asserted in state group 52, a transition is invoked 
to group 54, in which ackl is asserted. 

Tableau 50 is a sort of virtual device, 
corresponding to actual target device 40. Appendix B 
accordingly contains source code in VHDL representing a 
tableau similar to tableau 50 as a device model. In 
preferred embodiments of the present invention, this 
virtual device is tested to determine whether its 
states and transitions correspond exactly to those of 
the actual device, or equivalently whether the behavior 
of the virtual device under all possible combinations 
of input conditions is identical to that of the model 
of the actual device. If differences are found, they 
are then indicative either that the tableau (and hence 
the specified properties) are incomplete or that the 
model itself is incomplete. Methods and criteria for 
testing tableau 50 are described further hereinbelow. 

Fig. 4 is a flow chart that schematically 
illustrates a method for verifying a specification of 
model checking properties by comparing tableau 50 with 
device 40, in accordance with a preferred embodiment of 
the present invention. The method begins with 

preparation of the specification, such as the formula V|/ 
listed in Table II, and checking the device model M to 
ensure that the model satisfies the specification, 
i.e., that Mt=v|/. The specification is then used to 
construct the tableau. As shown in Fig. 2, tableau 50 
as a virtual device model has virtual inputs 72 and 
outputs 74, corresponding respectively to inputs 42 and 
outputs 44 of implementation model 40 of the target 
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device. For the purpose of testing the tableau against 
the implementation model, the tableau inputs are 
* labeled REQ0_SPEC and REQ1_SPEC, and the tableau 
outputs are labeled similarly, ACK0_SPEC and ACK1_SPEC. 

These input and output labels are inserted in a 
representation of the tableau, preferably in the form 
of suitable program code, as listed in Appendix B. IBM 
RuleBase, as described hereinabove, is capable of 
translating the VHDL code in Appendix B into the SMV 
language used by model checkers. In the example shown 
in Appendix B, the model of device 40 is simplified, 
relative to the definition in Tables I and II, in that 
the non-observable variable "robin" is not used. 
Instead, ackO always receives priority when a state in 
which there is no active request is followed by two 
active requests. 

In order to test the tableau against the device 
model, a new model is created, combining the original 
implementation model and the virtual device model of 
the tableau. Inputs 72 of tableau 50 are tied to the 
corresponding inputs 42 of implementation model 40, so 
that the implementation model and the tableau model 
will receive the same input signals. The new, combined 
model is then input to an automatic model checking 
program, such as SMV. The model checker is asked to 
verify that the following properties regarding the 
combined model outputs are always true of the combined 
model : 

ACK0==ACK0_SPEC 
ACK1==ACK1 SPEC 
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Alternatively, in certain cases, the two outputs may be 
checked separately, rather than in a single pass of the 
model checker, using separate tableaux corresponding to 
subsets of the specification properties that influence 
the particular outputs. 

If the above-mentioned properties of the combined model 
outputs' are confirmed, tableau 50 is assured of 
representing a complete and correct specification of 
device 40. If the tableau specification is not 

sufficiently detailed, then the tableau outputs 
ACKi_SFEC will not be as constrained as the model 
outputs ACKi, and there will be some combination of 
inputs under which ACKi_SPEC will have two possible 
values when ACKi can have only one. This outcome will 
generally lead engineer 24 to conclude that an 
additional constraint is required, i.e., that a further 
property is needed in the specification. Typically, a 
suitable property is added and the specification is 
re-checked, repeating the steps described above. If 
now ACKi==ACKi__SPEC, then the specification can be 
considered complete and correct. Alternatively, it may 
turn out that evaluation of the model and specification 
in this manner will lead engineer 24 to conclude that 
there is an error in the implementation model, such as 
a missing state or transition, which causes the outputs 
of the model and the tableau differ. It is a further 
advantage of automatic model checking programs that 
they provide evidence of such errors, in the form of 
"counter-examples," that assist the engineer in 
identifying and correcting the error. 

Fig. 5 is a flow chart that schematically 
illustrates another method for verifying a model 
checking specification, in accordance with a preferred 
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embodiment of the present invention. The method 
begins, like the method of Fig. 4, with preparation of 
a specification of model properties and model checking 
to determine that the model satisfies the 
specification. The specification is then used to 
create a corresponding tableau, which is evaluated 
against the device implementation model. The method of 
Fig. 5 differs from the method of Fig. 4 in the manner 
in which the tableau is evaluated, as described 
hereinbelow. Whereas the method of Fig. 4 is useful 
primarily in checking deterministic models, the method 
of Fig. 5 can be used for substantially any model, 
including non-deterministic models. 

In order to evaluate the tableau against the 
model, a simulation preorder, SIM, is calculated for 
the model and the tableau. SIM is a relation between 
the model M and the tableau T (SIM G M x T) containing 
pairs of states (s,s') in M and T, respectively. SIM 
satisfies the following requirements: 

o For every initial state s 0 of M, there is an 
initial state s 0 ' of T, such that (s 0 /S 0 ') belongs 
to SIM. 

o For every pair of states (s,s') in SIM, state s 
is characterized by the same set of atomic 
propositions as s' (i.e., the same values of the 
variables ACKi and REQi in the example of device 
40) . 

o For every state-to-state transition from state 
s, there is a corresponding transition for state 
s' (although not necessarily a one-to-one 
correspondence) . 
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A formal definition and method for computation of SIM 
are presented in Appendix C hereinbelow. 

Based on the simulation preorder SIM, a reachable 
simulation preorder for M and T, ReachSIM is 
determined. T may contain paths by which a state s is 
reached from an initial state, which do not have 
corresponding permissible paths in M. ReachSIM c SIM 
contains only pairs of states (s,s') characterized in 
that states s and s' are reached by corresponding paths 

k and 7t' from corresponding initial states. A path n = 

So/ Si, s, and a path %' = s 0 ' , Si', s' are 

considered to correspond if every pair of states 
(Si,Si') along the paths belongs to SIM. Details of 
the computation of ReachSIM are similarly presented in 
Appendix C. 

ReachSIM thus identifies a set of states in T 
having transitions that correspond to the actual 
transitions in M. There may yet be, however, states or 
transitions in T that do not have corresponding states 
or transitions in M, meaning that the specification 
does not constrain the implementation model tightly 
enough, so that one or more additional properties are 
needed. Such states and transitions are referred to 
herein as being "unimplemented." There may likewise be 
states in T that correspond simultaneously to two or 
more states in M. Such discrepancies are detected 
using ReachSIM to evaluate the following criteria, 
either serially or in parallel: 

o Unimplemented start states: These are initial 
tableau states that have no corresponding initial 
states- in the model (and therefore are absent 
from ReachSIM) . The existence of an 



IS999-035 



21 



35277S3 



unimplemented start state indicates either that 
the specification does not adequately constrain 
the start states, or that the model is lacking a 
required initial state, 
o Unimplemented states: The existence of a state 
anywhere in the tableau that is not included in 
ReachSIM indicates either that the specification 
is lacking in constraints or that a .meaningful 
state of the device is not implemented in the 
model . 

o Unimplemented transitions: These are 

transitions between states of the tableau for 
which there is no corresponding transition in the 
model. The states belong to ReachSIM, so that 
they have corresponding states in the model, 
which are reached by corresponding paths. The 
existence of an unimplemented transition 
indicates either that the specification is not 
tight enough or that a required transition, 
between reachable implementation states, was not 
implemented in the model, 
o Many-to-one mapping: In this case, there may 
be a tableau state to which multiple 
implementation states are mapped, i.e., a state s 
which is paired in ReachSIM with at least two 
different model states s t ' and s/ . The existence 
of a many-to-one state indicates either that the 
specification is not sufficiently detailed, or 
that the implementation contains redundancies. 
If the first three of these four criteria return 

empty results, then T is a complete specif ication of M. 

Any dissimilarity between . the tableau and the 
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implementation will result in a non-empty result. 
Preferably, the tableau T that is used in this method 
is a reduced tableau, as defined in Appendix A, since 
traditional (non-reduced) tableaux typically contain 
5 redundancies, which are removed in the reduced tableau. 
If the first three of the criteria above hold (i.e., 
return empty results), T and M are bisimilar, and the 
fourth criterion is not necessary to establish the 
completeness of T. It may, however, indicate that 
10 there are redundancies in the implementation. 

As noted hereinabove, verification of 

specification properties vis-a-vis the implementation 
model, using any of the methods described herein, is 
preferably carried out using software for this purpose 
15 running on processor 22. Software for use in such 
verification is preferably supplied as component of a 
simulation and model checking software package. 
Alternatively, the software for tableau construction 
and verification is provided as an independent software 
20 package. In either case, the software may be conveyed 
to processor 22 in intangible form, over a network, for 
example, or on tangible media, such as CD-ROM. 

Although preferred embodiments are described 
hereinabove with reference to certain methods and 
25 languages used in model checking, it will be understood 
that the application of the present invention is not 
limited to any particular language or method of 
implementation. Those skilled in the art will 

appreciate that the principles of the present invention 
30 may similarly be used in other areas of verification, 
not only for electronic devices, but also in 
verification of other types of target systems, as well, 
for example, transportation systems or complex valve 
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manifolds. It will thus be understood that the 
preferred embodiments described above are cited by way 
of example, and the full scope of the invention is 
limited only by the claims. 
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APPENDIX A 

REDUCED TABLEAU FOR ACTL - DEFINITION AND ALGORITHM 
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1 Reduced Tableau for ACTL 



In this section we define a reduced tableau for the subset of ACTL safety formulas. We follow 
the definition of the reduced tableau for LTL presented in [2]. A tableau is a special form of a 
Kripke structure, consisting of states labeled with atomic propositions and transitions between the 
states. As is often the case with tableaux for temporal logics (e.g. [1]), a state of the tableau 
consists of a set of formulas that are supposed to hold along all paths leaving the state. Unlike 
typical tableaux, however, the formulas in the states of the reduced tableau are interpreted over a 
three- valued domain. Thus, a state may include a formula or its negation, or none of the two. If 
the latter occurs, it reflects a "don't care" situation, i.e., the formula may be either true or false in 
the state. 

Similarly to [l], we wish the reduced tableau for a formula ^ to satisfy <j>. Furthermore, it should 
be greater by the simulation preorder [3] than any Kripke structure that satisfies tp. In order to 
achieve these goals we will adapt both definitions of f= and simulation preorder to be applicable to 
three-valued structures. Below we present the formal definitions of the tableau and of the adapted 
relations. 

Let AP^ be the set of atomic propositions in an ACTL formula ifr . 
Definition 1.1 (sub-formulas) The set o/sub-formulas of ip is defined recursively as follows : 

1. sub(p) = {p} and sub(^p) = if p € AP^ 

2. sub(<p) = {(f} U sub(gi) U sub(g 2 ), if = g x A g 2 or <p = g x V g 2 . 

3. sub{AXg x ) = {AXg x }U sub{g l ) 

4- sub{A[g x Wg 2 )) = {A[g x Wg 2 }, AX A[ gi Wg 2 ]} U sub(g x ) U sub{g 2 ) 

We will distinguish between a-formulas and /^-formulas, which are conjunctions and disjunc- 
tions, respectively. In the reduced tableau, if a state contains a conjunction, then it also contains 
its two conjuncts. On the other hand, if it contains a disjunction, it will usually contain only one 
of the disjunct, leaving the other as "don't care". 

Definition 1.2 (a-formula) A formula g € sub(ip) is an a-formula if g = g x A g 2 . In this case 
we define a set of formulas k(g) = {g X) g 2 }. 

Definition 1.3 (/3-formula) A formula g £ sub(tp) is a /3-formula if : 

1. g — g x V g 2 , in which case k x [g) = {g x } and k 2 {g) = {g 2 }. 

2. g = A[g x Wg 2 ], in which case k x {g) = {g 2 } and k 2 (g) = {g x , AX A[g x Wg 2 ]} . 
Definition 1.4 (A particle) A set of formulas P is a particle if: 

L PC sub{<ifj) 

2. p€ P -+^p £ P 

3. ->p € P -> p £ P 

4* For every a-formula g € sub(tp), g £ P iff k(g) C P 

5. For every (3-formula g € sub(?fi), g £ P iff either k x {g) C P or k 2 (g) C P or both. 



Definition 1.5 (Implied successor) A formula g is an implied successor of a particle P if 
AXg G P. We denote ky imps(P) the set of implied successors of P i.e., imps(P) == {g\AXg G P} 

Note that if P does not include any formula of the form AXg then imps(P) = {} . The particle 
{} means that the state reached has no commitments to satisfy any of the formulas. Thus, it may 
be the start of any possible paths. Furthermore, it may simulate any state. We later see that the 
only son of particle {} is the particle {} itself. 

Definition 1.6 (/.v-closed) A set of formulas B is a-closed, if for every a-formula r G sub(ip), 
r G B iff k(r) C B. The a-closure of a set B is the smallest a-closed set containing B. 

Definition 1.7 (/^-closed) A set of formulas B is fi-closed, if for every (3-formula r G sub(ip), 
r G B iff either k^r) C B or k 2 (r) C B (or both). 

Function : Remove Redundant 
function Remove Redundant (Set of particles) returns : Set of particles 

This function receives a set of particles, and returns a set such that : For each one of the elements 
in the set, The element will stay in the set if it does not include any other element in the set, and 
will be removed otherwise. . 
Function : cover p 

recursive function cover p (B : Set of formulas) returns : Set of particles 
if B is not locally consistent then return {} - no particles contain 5 
if B is not a-closed then return cover p (a-closure(ZJ)) 

if there exists some /3-formula r 6 sub(tp) such that r £ B but k x (r) g B or k 2 (r) C B then return 
cover p (B U {r}) 

if there exists some /3-formula r € B but both k x (r) and k 2 {r) are not in B 
then return Remove Redundant (cover p (B U {ki(r)}) U cover p (B U {k 2 (r)})) 
return B - B is a particle 
end function 

Definition 1.8 (Successors p (P)) Successor s p (P) = cover p (imps(P)) . 

We now describe an iterative algorithm PART -TAB that produces the tableau r(^) =< 5 r , 5 r o, Rr, L T 
for 0. 

Algorithm : PART .TAB 
S tQ := cover p ({4)}) 
S r := S T Q 
R r :=9 

Mark all particles in S T as unprocessed 
For each unprocessed particle P in S T do 
S ~ successors p (P)] 
For each Q S S 
Add (P,Q) to R T ; 

Define L(P) = PC) {{p\p G AP*} U {-*p\p G AP+} 

UQtSr; 

Add Q to S T ; 

Mark Q as unprocessed; 

end for 
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Mark P 
end for 
eud for 



as processed; 



Note that a state is labeled by propositions from AP and by their negations. Since a state is 
a particle, it will never contain both a proposition and its negation, but it may contain none of 
them. 
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APPENDIX B 

The following is a program listing in VHDL 
describing a tableau that corresponds generally to the 
properties of arbiter 40 listed in Table II. As noted 
hereinabove, however, the listing below is based on a 
simplified model without the non-observable variable 
"robin.' 7 In place of the output names ACK0_SPEC and 
ACK1_SPEC shown in Fig. 2, the names ack0_new and 
ackl_new are used in the listing; and reqO and reql in 
the listing correspond respectively to REQ0_SPEC and 
REQ1_SPEC. 

library ieee; 

use ieee . std_logic_l 1 64 . all ; 

entity full_spec is 
port ( 



rb_clock 


: in std_ulogic; 


ack0_new 


: in std_ulogic; 


ackl_new 


: in std_ulogic; 


reqO 


: in std ulogic; 


reql 


: in std_ulogic; 


reset 


: in std_ulogic; 


fails 


: out 




std ulogic vector (0 



end full__spec; 

architecture rb of full_spec is 

signal not__rb_rese t : std_ulogic ; 
signal rb_reset : std_ulogic ; 
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type rb_enum_type is (iu_enum_slash_err, 
iu_enum_slash_z) ; 

begin 
p: 

process 
begin 

wait until rb_clock 1 event and rb_clock= 1 1 1 ; 
not_rb_reset <= f l r ; 
end process; 

rb reset <= reset or (not not rb reset) ; 



f 1 : 

fails (0) <= not b21 ( ( ( ( (not ack0_new) or (not 
ackl_new) ) ) /= '0 T ) 

or (rb_reset /= ? 0 f ) or (rb_clock /= f l f )); 
f2 : 
block 

constant n: integer := 4; 

signal v: std_ulogic_vector ( 0 to n-1) := 
"1110"; 

signal v^out: std_ulogic_vector ( 0 to n-1); 

signal vnext: std_ulogic_vector ( 0 to n-1); 

signal ok: std_ulogic := ? l f ; 
begin 
v_out(0) <= '0'; 
v_out(l) <= v(l) and ( f l f ); 

v_out(2) <= v(2) and (((not reqO) and (not 
reql))); 

v_out(3) <= v(3) and ((not ((not ack0_new) and 
(not ackl_new) ) ) ) ; 
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vnext(O) <= ' O f ; 

vnext(l) <= v_out(l); 

vnext(2) <= v_out(l); 

vnext (3) <= v out (2) ; 



P: 

process 
begin 

wait until rb_clock'event and rb_clock= ' 1 T ; 
if rb_reset = then 
v <= "1110"; 
ok <= 1 1 1 ; 

else 

if (not (v(3) and (not ((not ack0_new) 
and (not ackl_new) ) 

))) = f 0' then 

ok <= 1 0 1 ; 
elsif ok = f 0 T then 

ok <= 1 1 T ; 
end if; 



v <= vnext; 
end if; 
end process; 



fails (1) <= not b21 ((ok /= f 0 f ) or (rb_reset 
/= r 0 f ) 

or (rb_clock /= 1 1 1 ) ) ; 
end block; 

f3: 
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block 

constant n: integer := 4; 

signal v: std_ulogic_vector ( 0 to n-1) :~ 
"1110"; 

signal v_out : s td_ulogic_vector ( 0 to n-1); 

signal vnext : std_ulogic_vector ( 0 to n-1); 

signal ok: std_ulogic := ' 1'; 
begin 
v_out(0) <= f 0 f ; 
v_out(l) <= v(l) and ( T l ? ); 

v_out(2) <= v(2) and ( (reqO and (not ack0_new) ) ) 
v out (3) <= v(3) and ((not ackO new)); 



vnext (0) <= f 0 r ; 

vnext (1) <= v_out(l); 

vnext (2) <= v_out(l); 

vnext (3) <= v out (2) ; 



process 
begin 

wait until rb_clock T event and rb__clock= 1 1 1 ; 
if rb_reset = f l f then 
v <= "1110"; 
ok <= '1'; 

else 

if (not (v(3) and (not ackO^new) ) ) = 
'0' then 

ok <- '0'; 
elsif ok = f 0 1 then 

ok <= r l ' ; 
end if; 
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10 



v <= vnext; 
end if; 
end process; 



fails (2) <= not b21 ((ok /= r 0 f ) or (rb_reset 
/= '0') 

or (rb_clock /= 1 1 f ) ) ; 
end block; 



f4: 

block 

constant n: integer : = 4;. 

signal v: std_ulogic_vector ( 0 to n-1) := 
15 "1110"; 

signal v_out : std_ulogic_vector (0 ' to n-1); 
signal vnext: s td_ulogic_vector ( 0 to n-1); 
signal ok: std_ulogic : = 1 1 f ; 
begin 

2 0 v_out(0) <= r 0 f ; 

v__out ( 1 ) <= v ( 1 ) and ( f 1 T ) ; 

v_out(2) <= v(2) and (((not reqO) and reql)); 
v__out(3) <= v(3) and {(not ackl_new) ) ; 

25 vnext (0) <= f 0'; 

vnext (1) <= v_out(l); 

vnext (2) <= v_out(l); 

vnext (3) <= v_out (2) ; 

30 p: 

process 
begin 

wait until rb_c lock ' event and rb__clock= ' 1 1 ; 
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if rb_reset = 1 l f then 
v <= "1110"; 
ok <= ' 1 f ; 

else 

if (not (v(3) and (not ackl_new) ) ) = 
f 0 ? then 

ok <= r 0 f ; 
elsif ok = f 0 f then 

ok <= ' 1 1 ; 
end if; 



v <= vnext; 
end if; 
end process; 



fails (3) <= not b21 ((ok /= ' 0') or (rb__reset 
/= T 0') 

or (rb_clock /= 1 1 f ) ) ; 
end block;. 

f5: 

block 

constant n: integer := 4; 

signal v: std_ulogic_vector ( 0 to n-1) := 
"1110"; 

signal v_out: std_ulogic_vector (0 to n-1); 

signal vnext: std__ulogic_vector (0 to n-1); 

signal ok: std_ulogic := ' l 1 ; 
begin 
v_out(0.) <= f 0 f ; 
v_out(l) <= v(l) and ( f l f ); 

v_out{2) <= v(2) and ( (reql and ack0_new) ') ; 
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v_out(3) <= v(3) and ((not ackl new)); 



vnext (0) <= f 0 ' ; 

vnext(l) <= v_out(l) 

5 vnext (2) <= v_out(l) 

vnext (3) <= v out (2) 



process 
10 begin 

wait until rb__clock f event and rb_clock= 1 1 f ; 
if rb^reset = 'l f then 
v <= "1110"; 
ok <= T ; 

15 else 

if (not (v(3) and (not ackl_new) ) ) 
'0 f then 
ok <= r 0 r ; 
elsif ok = f 0 f then 
20 ok <= f 1 T ; 

end if; 

v <= vnext; 
end if; 
25 end process; 



fails (4) <= not b21 ((ok /= f 0 f ) or (rb_reset 
/= '0') 

30 or (rb_clock /= f l ! )); 

end block; 



f6: 
IS999-035 



35277S3 



block 

constant n: integer : = 4; 

signal v: std_ulogic_vector ( 0 to n-1) := 
"1110"; 

signal v_out : s td_ulogic_vector ( 0 to n-1) 
signal vnext: std_ulogic_vec tor ( 0 to n-1) 
signal ok: std_ulogic := f l f ; 
begin 

v_out(0) <= T 0 f ; 

v_out(l) <= v(l) and ( 1 1 1 ) ; 

v_out(2) <= v(2) and ( (reqO and (not reql))) 
v out(3) <= v(3) and ((not ackO new)); 



vnext ( 0 ) 
vnext ( 1 ) 
vnext (2) 
vnext (3) 



f 0* ; 

v_out (1) 
v_out ( 1 ) 
v out (2) 



<= 
<= 
<= 
<= 



P: 

process 
begin 

wait until rb_clock T event and rb_clock= T 1 f ; 
if rb_reset = f l' then 
v <= "1110"; 
ok <= 1 1 1 ; 

else 

if (not (v(3) and (not ack0_new) ) ) 
f 0 f then 

ok <= 1 0 f ; 
elsif ok = ! 0 1 then 

ok <= f 1 1 ; 
end if; 
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v <= vnext; 
end if; 
end process; 



fails (5) <= not b21 ((ok /= '0') or (rb_reset 
/= *0') 

or (rb_clock /= * 1 ' ) ) ; 
end block; 

end rb ; 
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APPENDIX C 

DEFINITION OF TERMS AND COMPARISON CRITERIA 



IS999-035 



38 



"Have X written enough properties?" - 
A method of comparison between specification 
and implementation 



Abstract. This work presents a novel approach for evaluating the qual- 
ity of the model checking process. Given a model of a design (or imple- 
mentation) and a temporal logic formula that describes a specification, 
model checking determines whether the model satisfies the specification. 
Assume. that all specification formulas were successfully checked for the 
implementation. Are we sure that the implementation is correct? If the 
specification is incomplete, we may fail to find an error in the imple- 
mentation. On the other hand, if the specification is complete, then the 
model checking process can be stopped without adding more specifica- 
tion formulas. Thus, knowing whether the specification is complete may 
both avoid missed implementation errors and save precious verification 
time. 

The completeness of a specification with respect to a given implemen- 
tation is determined as follows. The specification formula is first trans- 
formed into a tableau. The simulation preorder is then used to compare 
the implementation model and the tableau model. We suggest four com- 
parison criteria, each revealing a certain dissimilarity between the im- 
plementation and the specification. If all comparison criteria are empty, 
we conclude that the tableau is bisimilar to the implementation model 
and that the specification fully describes the implementation. We also 
conclude that there are no redundant states in the implementation. 
The method is exemplified on a small hardware example. We imple- 
mented our method symbolically as an extension to SMV. The implemen- 
tation involves efficient OBDD manipulations that reduce the number of 
OBDD variables from 4n to 2n. 



1 Introduction 

This work presents a novel approach for evaluating the quality of the model 
checking process. Given a model of the design (or implementation) and a tempo- 
ral logic formula that describes a specification, model checking [8, 2] determines 
whether the model satisfies the specification. 

Assume that all specification formulas were successfully checked for the im- 
plementation. Are we sure that the implementation is correct? If the specifica- 
tion is incomplete, we may fail to find an error in the implementation. On the 
other hand, if the specification is complete, then the model checking process can 
be stopped without checking additional specification formulas. Thus, knowing 
whether the specification is complete may both avoid missed implementation 
errors and save precious verification time. 
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Below we describe our method to determine whether a specification is com- 
plete with respect to a given implementation. We restrict our attention to safety 
properties written in the universal branching-time logic ACTL [3]. This logic is 
relatively restricted, but can still express most of the specifications used in prac- 
tice. Moreover, it can fully characterizes every deterministic implementation. We 
consider -a single specification formula (the conjunction of all properties). 

We first apply model checking to verify that the specification formula is true 
for the implementation model. The formula is then transformed into a tableau [3]. 
By definition, since the formula is true for the model, the tableau is greater by 
the simulation preorder[9] than the model. 

We defined a reduced tableau for ACTL safety formulas. Our tableau is based 
on the Particle tableau for LTL, presented in [6]. We further reduce their tableau 
by removing redundant tableau states. 

We next use the simulation preorder to find differences between the imple- 
mentation and its specification. For example, if we find a reachable tableau state 
with no corresponding implementation state, then we argue that one of the two 
holds. Either the specification is not restrictive enough or the implementation 
fails to implement a meaningful state. Our method will not be able to determine 
which of the arguments is correct. However, the evidence for the dissimilarity 
(in this case a tableau state that none of the implementation states are mapped 
to) will assist the designer to make the decision. 

We suggest four comparison criteria, each revealing a certain dissimilarity be- 
tween the implementation and specification. If all comparison criteria are empty, 
we conclude that the tableau is bisimilar to the implementation model and that 
the specification fully describes the implementation. We also conclude that there 
are no redundant states in the implementation. 

The practical aspects of this method are straightforward. Model checking 
activity in industry executes the following methodology: A verification engineer 
reads the specification, sets up a work environment and then proceeds to present 
the model checker with a sequence of properties in order to verify the design 
correctness [1]. The design (or implementation) on which this activity is executed 
can be quite large nowadays. As a result the set of properties written and verified 
becomes large as well, to the point that the engineer loses control over it. 

A large property set makes it necessary to construct tools to evaluate its 
overall quality. The basic question to answer is: "Have I written enough prop- 
erties?". The current solution is to manually review the property set. However, 
this solution is not scalable and furthermore since it is done manually it makes 
the description of model checking as "formal verification" imprecise. This in- 
adequate solution indicates a growing need for tools that may be able to tell 
the engineer when the design is "bug-free" and therefore cut down development 
time. 

Quality evaluation of verification activity is not new. Traditional verification 
methods have developed measurement criteria to measure the quality of test 
suites [11]. This area of verification is called coverage. The notion of coverage 
in model checking is to have a specification that covers the entire functionality 
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required from the implementation. This can be divided into two questions: 

L. Whether the environment is rich enough to provide all possible input se- 
quences. 

2. Whether the specification contains a sufficient set of properties. 

The method we present addresses both problems as will be later shown by an 
example. 

We compared a small hardware example with the reduced tableau. For the 
complete specification formula we received a reduced tableau with 20 states. The 
tableau presented in [3] would have a state space of 2 15 states for this formula. 
It is interesting to note that in this example not all the implementation variables 
are observable. 

We implemented our method symbolically as an extension to the symbolic 
model checker SMV [7]. Given a model with n state variables, a straightforward 
implementation of this method can create intermediate results that consists of 
4n OBDD variables. However, our implementation reduces the required number 
of OBDD variables from 4n to 2n. 

The main contributions of our paper can be summarized as follows: 

- We suggest for the first time a theoretical framework that provides quality 
evaluation for model checking. The suggested comparison criteria can assist 
the designer in finding errors in the design by indicating points in which the 
design and the specification disagree, and suggest criteria for terminating 
the verification effort. 

- We implemented our method symbolically within SMV. Thus, it can be 
invoked automatically once the model checking terminates successfully. 

Of a special interest is the symbolic computation of the simulation relation 
for which no good symbolic algorithm is known. 

- We defined a new reduced tableau for ACTL that is often significantly 
smaller in the number of states and transitions than known tableaux for 
ACTL. 

In these days, another work on coverage of model checking has been inde- 
pendently developed [5]. The work computes the percentage of states in which a 
change in an observable proposition will not affect the correctness of the specifi- 
cation. Their evidence is closely related to our criterion of Unimplemented State. 
In their paper they list a number of limitations of their work. They are unable 
to give path evidence, cannot point out functionality missing in the model, and 
they have no indication that the specification is complete. In the conclusion we 
explain how our work solves these problems. 

The analysis we perform compares the two models and tries to identify dis- 
similarities. It is therefore related to tautology checking of finite state machines 
as is done in [10]. However the method in [10] is suggested as an alternative to 
model checking and not as a complementary method. 

The rest of this paper is organized as follows. Section 2 gives the necessary 
background. Section 3 describes the comparison criteria and the method for their 



use. Section 4 exemplifies the different criteria by applying the method to a small 
hardware circuit. Section 5 presents symbolic algorithms that implement our 
method. In Section 6 we discuss the reduced tableau for ACTL safety formulas. 
Finally, the last section describes future work and concludes the paper. 

2 Preliminaries 

Our specification language is the universal branching-time temporal logic ACTL 
[3], restricted to safety properties. Let AP be a set of atomic propositions. The set 
of ACTL safety formulas is defined inductively in negation normal form, where 
negations are applied only to atomic propositions. It consists of the temporal 
operators X ("next-state") and W ("weak until") and the path quantifier A 
("for all paths"). 

- If p G AP then both p and -«p are ACTL safety formulas. 

- If <p\ and (p2 are ACTL safety formulas then so are p\ A <p2, <Pi V <P2> AXy?i , 
and A^iW^f. 

We use Kripke structures to model our implementations. A Kripke structure 
is a tuple M = (5, So, R, I) where 5 is a finite set of states; So C S is the set 
of initial states; R C S x S is the transition relation that must be total; and 
L : S —¥ 2 AP is the labeling function that maps each state to the set of atomic 
propositions true at that state. 

A path in M from a state s is a sequence so, si, . . ■ such that sq — s and for 
every i, (s;, s,- + i) € R. 

The logic ACTL is interpreted over a state s in a Kripke structure M . The 
formal definition is omitted here. Intuitively, AXy?j is true in s if all its successors 
satisfy <p\. A[^iW^] is true in s if along every path from s, either <pi holds 
forever or <p2 eventually holds and <p x holds up to that point. We say that a 
structure M satisfies a formula <p, denoted M f= (p, if every initial state of M 
satisfies <p. 

Let M - {S,Sq,R } L) and AT = (S' , S' Q , R' , L') be two Kripke structures 
over the same set of atomic propositions AP. A relation SIM C S x S' is a 
simulation preorder from M to M 1 [9] if for every initial state sq of M there is 
an initial state s' Q of M' such that (so,s 0 ) 6 SIM, Moreover, if (s,s') £ SIM 
then the following holds: 

- L(s) = L'(s'), and 

- Vsxfts^i) e 3*i[(*',*i) Ei?A € SIM]]. 

If there is a simulation preorder from M to M', we write iV/ < M' and say that 
M simulates M' '. 

It is well known [3] that if M < A/' then for every ACTL formula <p t if 
M f (= 9? then A/ |= <p. Furthermore, for every ACTL safety formula it is 

1 Full ACTL includes also formulas of the form A[v?i U92] ("strong until"). 



possible to construct a Kripke structure T(0), called a tableau 2 for 0, that has 
the following tableau properties [3]. 

- For every structure AT", M )= ^ < ^ = = :: ^ M < T(^). 

Intuitively, the simulation preorder relates two .states if the computation tree 
starting from the state of the smaller model can be embedded in the computation 
tree starting from the state of the greater one. This, however, is not sufficient 
in order to determine how similar the two structures are. Instead, we use the 
reachable simulation preorder that relates two states if they are in the simulation 
preorder and are also reachable from initial states along corresponding paths. 

Formally, let SIM C S x S' be the greatest simulation preorder from M to 
M f . The reachable simulation preorder (or SIM, ReachSIM C SIM , is defined 
by: (s, s') € ReachSIM if and only if there is a path n = so, 5 i» * • ■ 1 s k in M 
with So € So and sjt = s and a path tt' — s' 0 , s\ , . . . , s' k in M' with s' Q € S' Q and 
s' k = s' such that for all 0 < j < *, (s,, s}) € S/M. 

In this case, the paths tt and tt' are called corresponding paths leading to s and 

s'. 

Lemma 1. ReachSIM is a simulation preorder from M to M f . 
The proof of the lemma is postponed to Appendix A. 

3 Comparison Criteria 

Let M = (Si j Soit Ri 7 Li) be an implementation structure and T(ifr) = (St, So ti Rt, L t ) 
be a tableau structure over a common set of atomic propositions AP. For the 
two structures we consider only reachable states that are the start of an infinite 
path. 

Assume M < T(ip). We define four criteria, each is associated with a set. 
A criterion is said to hold if the appropriate set is empty. For convenience we 
name each criterion the same as the appropriate set. The following sets define 
the criteria : 

1. UnlmplementedStartState - {s t € Sot | Vs.- € So* [(s.*,*) € ReachSIM)} 
An Unimplemented Start State is an initial tableau state that has no corre- 
sponding initial state in the implementation structure. The existence of such 
a state may indicate that the specification does not properly constrain the 
set of start states. It may also indicate the lack of a required initial state in 
the implementation. 

2. Unimplemented St ate = {s t £ St | Vs,- £ S,- [(s,-, s t ) £ ReachSIM ] } 

An Unimplemented State is a state of the tableau that has no correspond- 
ing state in the implementation structure. This difference may suggest that 
the specification is not tight enough, or that a meaningful state was not 
implemented. 

2 The tableau for full ACTL is a fair Kripke structure (not defined here). It has the 
same properties except that f= and < are defined for fair structures. 
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3. UnfrnplementedTransition = {(s e ,sj) € ft [ 3s t - 1 sj £ 5,*, 
[(*.,<,<) € ReachSIM, (s<,s' t ) <= ReachSIM and (5,-,a{) g ft]} 

An Unimplemented Transition is a transition between two states of the 
tableau, for which a corresponding transition in the implementation does 
not exist. The existence of such a transition may suggest that the specifi- 
cation is not tight enough, or that a required transition (between reachable 
implementation states) was not implemented. 

4. ManyToOne = {s t € S t \3su,*2i 6 S,* [ (su, s t ) € ReachSIM, (s 2 i , s t ) € 
ReachSIM and su ^ s 2l :] } 

A Many To One state is a tableau state to which multiple implementation 
states are mapped. The existence of such a state may indicate that the spec- 
ification is not detailed enough. It may also suggest that the implementation 
contains redundancy. 

Our criteria are defined for any tableau that has the tableau properties as defined 
in Section 2. Any dissimilarity between the implementation and the specification 
will result in a non empty criterion. Empty criteria indicate completeness, but 
they are hard to obtain on traditional tableaux since such tableaux contain 
redundancies. In the reduced tableau presented in Section 6, redundancies are 
removed and therefore empty criteria are more likely to be achieved. 
Given a structure M and a property V our method consists of the following 
steps: 

1. Apply model checking to verify that M \= i>. 

2. Build a (reduced) tableau T(ip) for iff. 

3. Compute SIM of(M,T(^)). 

4. Compute ReachSIM of (AT, T(i>)) from SIM of (M,T(^)). 

5. For each of the comparison criteria, evaluate if its corresponding set is empty 
and if not present evidence for its failure. 

Theorem 2. Let M be an implementation model and ip be an ACTL safety 
formula such that M ^= ip. Let T{xb) be a tableau for ip that has the tableau 
properties. If the comparison criteria 1-3 hold then T(ip) < M. 

The proof of this theorem is left to Appendix B. The proof implies that if cri- 
teria 1-3 hold then T(tp) and M are in fact bisimilar. The fourth criterion is 
not necessary for completeness since whenever there are several non-bisimilar 
implementation states that are mapped to the same tableau state, then there is 
also an unimplemented state or transition. However, this criterion may reveal 
redundancies in the implementation. 

It is important to note that the goal is not to find a smaller set of criteria 
that guarantees the specification completeness. The purpose of the criteria is to 
assist the designer in the debugging process. Thus, we are looking for meaningful 
criteria that can distinguish among different types of problems and identify them. 
In Section 6 we define an additional criterion that can reveal redundancy in the 
specification. 




4 Example 



Consider a synchronous arbiter with two inputs, reqO, reqi and two outputs 
ackO, ackl. The assertion of acki is a response to the assertion of reqi. Initially, 
both outputs of the arbiter are inactive. At any time, at most one acknowledge 
output may be active. The arbiter grants one of the active requests in the next 
cycle, and uses a round robin algorithm in case both request inputs are active. 
Furthermore in the case of simultaneous assertion (i.e. both requests are asserted 
and were not asserted in the previous cycle), request 0 has priority in the first 
simultaneous assertion occurrence. In any additional occurrence of simultaneous 
assertion the priority rotates with respect to the previous occurrence. 
The implementation and the specification will share a common set of atomic 
propositions AP = {reqO, reqi, ackO } ackl}. An implementation of the arbiter 
M y written in the SMV language is presented below: 



1) 


var 






2) 


reqO, reqi, ackQ, ackl, robin : 


boolean; 


3) 


assign 






4) 


init(ackO) := 0; 






5) 


init(ackl) := 0; 






6) 


init (robin) := 0; 






7) 


next(ackO) := case 






8) 


\req0 


:0; 


- No request results no ack 


9) 


\reql 


: l; 


- A single request 


10) 


\ack0ic\ackl 


: [robin; 


- Simultaneous requests assertions 


11) 


1 


: lackO; 


- Both requesting , toggle ack 


12) 


esac; 






13) 


next(ackl) := case 






14) 


\reql 


:0; 


- No request results no ack 


15) 


IreqQ 


: i; 


- A single request 


16) 


\ack0h \ackl 


: robin; 


- simultaneous assertion 


17) 


1 


:\ackl; 


- Both requesting , toggle ack 


18) 


esac; 






19) 


next(robin) := if re 


qO & reqi folackQ & lackl then \robin 


20) 




else robin endif ; - Two simultaneous request 



From the verbal description given at the beginning of the section, one may derive 
a temporal formula that specifies the arbiter : 

ip = -lac&O A ->acA:lA 

A[(-re?0 V -regl V ackO V ackl)W 

(reqO A reqi A ~>ack0 A -^ackl A AXacArO)] A - <Po 

AG( 

(->ack0 V -lackl) A — <pi 
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(-ircf/O A -*>req I AX(~-acA;0 A ^acA* I)) 
(retfO A -17N27I — ► AXac/rO) 
(-*reqO A reql —r AXackl) 
(re? I A acA-0 AXackl) 
{reqO A acH -+ AXackO) 

{reqO A rer/L A ->ackQ A^ackl AX(ac*0 -> 
Af^reyO V ^reql V acJtO V ackl)W 

(reqO A rer/L A ^ackO A ^ackl A AXacArl)])) 
(re?0 A reql A -<acA:0 A ->acAr I AX(acfcl -> 
A((-nre<70 V ^reql V ac*0 V ackl)W 

{reqO A reqri A ^ackO A -iacH A AXacA'O)])) 

where AG<p = A[(pW false]. We verified that M ^= ^ using the SMV model 
checker. We then applied our method. We found that all comparison criteria 
hold. We therefore concluded that ip is a complete specification for M. 
In order to exemplify the ability of our method we changed the implementation 
and the specification in different ways. In all cases the modified implementation 
satisfied the modified specification. However, our method reported the failure of 
some of the criteria. By examining the evidence supplied by the report, we could 
detect flaws in either the implementation or the specification. 

4.1 Unimplemented Transition evidence 

Consider a modified version of the implementation M, named M tr ans obtained 

by adding the line : robin &c ackl : {0, 1}; 

between line (10) and line (11), and by adding the line : 

ackl : \next(ackQ)\ between line (16) and line (17). 

Consider also the modified formula Mtrans obtained from tp by replacing <pe with: 
(reqO A ackl -+ AX(acfcO V acArl))A 

SMV shows that M trans f= Mtrans - However, applying the comparison method on 
Mtrans and iptrans, reports an Unimplemented Transition. It supplies as an evi- 
dence a transition between tableau states s t and s' t such that L t {s t ) = L t {s f t ) = 
{reqO, reql, lackQ, acArl}. Such a transition is possible by iptrans but not possible 
in Mtrans in case variable robin is not asserted. 

If we check the reason for the incomplete specification we note that the 
evidence shows a cycle with reqO and ackl asserted followed by a cycle were 
ackl is asserted. This ill behavior violates the round robin requirement. The 
complete specification would detect that M trans has a bug, since M tr ans ^= ^. 

4.2 Unimplemented state evidence 

Consider a modified version of the implementation M, named M un im P obtained 
by adding line : ackQ ; {0,1}; 

between lines (10) and line (11), and replacing line (2) with the following lines: 
2.1) reqQJemp, reql, ac&O, acArl, robin : boolean; 



A - (p n 

A - tp 3 

A - <p 4 

A - v?5 

A - <p 6 

A - <p 7 

) " 



2.2) define r<tq{) := reqOJernp &c \(ackQ & ackl); 

Here reqOJnmp is a free variable, and the input re70 is a restricted input such 
that if the state satisfies ackQ&cackl then reqO is forced to be inactive. 
Consider' also the modified formula Munimp obtained from lp by deleting tpi. 
SMV shows that Munimp (= rpunimp- However, applying the comparison method 
on M tin imp and ifiimimp* reports an Unimplemented State. It supplies as an ev- 
idence the state s t such that L t (s t ) = {reqO, \req I, ackO, ackl}. This state is 
possible by ip U nim P but not possible in iV/ unimp . 

If we check the source of the incomplete specification we note that the evidence 
violates the mutual exclusion property. Both of the arbiter outputs ackO and 
ackl are active. The complete specification would detect that M un imp has a 
bug, since 

Note that in this example we can also identify that reqO in M un imp is a restricted 
input relative to the formula 4> U nimp- The state space of M un i mp does not in- 
clude the states {reqO, reql, ackO, ackl} or {reqO, \reql, ackO, ackl}. A restricted 
environment may hide bugs, so this is just as important as finding missing prop- 
erties. 



4.3 Many To One evidence 

A nonempty Many To One criterion may imply one of two cases. Redundant 
implementation, or incompleteness. The latter case is always accompanied with 
one of criteria 1-3. The former case where criteria 1-3 hold but we have a Many 
To One evidence implies that the implementation is complete with respect to the 
specification, but it is not efficient and contains redundancies. There is a smaller 
implementation that can preserve the completeness. This information may give 
insight on the efficiency of the implementation. 

The following implementation M m 2o uses 5 implementation variables and two 
free inputs instead of 3 variables and two inputs of implementation M. Criteria 
1-3 are met for M m 2 0 with respect to tp. 



1) var 

2) reqO ) reql, reqQq, reqlq, ackOq } acklq, robin 

3) assign 

4) init(reqOq) := 0; init(reqlq) := 0; 

5) init(ackOq) := 0; init (acklq) := 0; 

6) init (robin) :— 1; 

7) define 

8) ackO := case 

9) IreqOq : 0; 

10) Ireqlq : 1; 

11) \ack0q & lacklq :\robin\ 

12) 1 : \ack0q\ 

13) esac\ 

14) acArl := case 



boolean; 



No request results no ack 
A single request 

Simultaneous requests assertions 
Both requesting , toggle ack 
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- No request results no ack 

- A single request 

- simultaneous assertion 

- Both requesting , toggle ack 



15) \req[q : 0; 

16) Weqtiq : 1; 
L7) lackOq & lacklq : robin; 

18) L :\acklq; 

19) escic; 

20) assign 

21) nex/(ro6in) := i/ re^O & reql klackQ & !acH */ien Irobin 

22) e/s€ robin endif; - Two simultaneous request assertions 

23) nex^rer/Otf) := rei/O; nex^retfl?) := reql; 

24) nex*(ac&0<7) := ackO; next(acklq) := acJfcl; 



Applying model checking will show that Af m3( > |= ^. 

In the above example we keep information of the current inputs reqO and reql, 
as well as their value in the previous cycle (i.e. reqOq and reqlq). Intuitively, 
this duplicates each state in M to four states in the state space of M m 2o- 



4.4 Unirnplemented Start State evidence 

The Unirnplemented Start State criterion does not hold when the specification is 
not restricted to the valid start states. Consider a specification formula obtained 
from -0 by removing the <po subformula. Applying the comparison method on M 
and the modified formula would yield a Unirnplemented Start State evidence of a 
tableau state s 0 t such that {ackO, \ackl} C L t (so t ). Restricting the specification 
to the valid start states would cause the Unirnplemented Start State criteria to 
hold. 



4.5 Non- Observable Implementation Variables 

As can be seen in this example, a state of the implementation is not uniquely 
determined by reqQ, reql, ackO and acArl. The variable robin effects the other 
variables, but it is a non-observable intermediate variable. This variable is not 
explicitly described in the specification, and does not appear in the common set 
of atomic propositions AP, referred to by the simulation preorder. Our criteria 
are defined with respect to observable variables only, but are not limited to 
systems where all the variables are observable. 



5 Implementation of the Method 
5.1 Symbolic Algorithms 

In this section we present the symbolic algorithms that implement various parts 
of our method. In particular, we show how to compute symbolically the sim- 
ulation relation. Our implementation will require less memory than the naive 
implementation since we reduce the number of OBDD variables. In Section 5.2 
we show how this is achieved. 

For conciseness, we use R(s, s'), S(s) etc. instead of (s, s') € R, s £ S. 



Computing SIM: Let M = (Si f Soi, R{, £,•) be the implementation structure 
and let T{ip) — (S t , Sot , Rt , I>t) be a tableau structure. The following pseudo- 
code depicts the algorithm for computing SIM : 
Init: S[M 0 (.Si,s t ) := { (s.-.a?*) 6 Si x St \ U(si) = L t (s t ) }; ; := 0 
Repeat { 

SIMj + { : = {(a if Se)|V.<-[fl t -(* if s;.) 35;(^(^.^)AS//V/ > ( 5 <,5 / ,)]]AS/M j ( 5|t s t )} 
j := j -f I } tmh/ S/Afj = SfMj-i 
SIM ;= 5AA/,- 

Computing ReachSJM: Given the simulation relation SIM of the pair (M, T(^)) 
the following pseudo-code depicts the algorithm for computing ReachSIM: 
Init: ReachSIMo := (So; x S 0( ) n SIM; j := 0 
Repeat { 

ReachSIMj + i := ReachSIMj U 

{ | Isi^StiReachSrMjisitSt) A /2 t (^ , 5<) A # £ (s c ,s' £ ) A S/M(s{, } 

7 := j + 1 } unr*7 ReachSIM j = ReachSIMj-i 
ReachSIM := ReachSIMj 

5.2 Efficient OBDD Implementation 

We now turn our attention to improving the performance of the algorithms 
described in the previous section. We assume that an implementation of such 
an algorithm will be done within a symbolic model checker such as SMV [7]. 
Since formal analysis always suffers from state explosion it is necessary to find 
methods to efficiently utilize computer memory. When working with OBDDs one 
possible way to do so is to try to minimize the number of OBDD variables that 
any OBDD created during the computation will have. 

We can see from the algorithms presented before that some of the sets, con- 
structed in intermediate computation steps, are defined over four sets of states: 
implementation states, specification states, tagged (next) implementation states, 
and tagged (next) specification states. For example, the computation of SIMj+i 
is defined by means of the implementation states s,-, specification states s t , tagged 
implementation states s\ (representing implementation next states), and tagged 
specification states s[ (representing specification next states). 

Assume that we need at most n bits to encode each set of states. Then po- 
tentially some of the OBDDs created in the intermediate computations will have 
An OBDD variables. However, by breaking the algorithm operations to smaller 
ones and manipulating OBDDs in a nonstandard way we managed to bound the 
number of variables of the OBDDs created in intermediate computations by 2n. 

We define two operations, compose and compose-odd, that operate on two *• 
OBDDs a and b over a total number of 3n variables. As explained later, the 
main advantage of these operations is that they can be implemented using only 
2n OBDD variables. 



compose(y, u) = 3x(a(x, y) A 6(x, u)) 
compose ~odd(y, u) = 3x(a(y, x) A b(\i, x)). 



(i) 

(2) 
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SIM and ReachSIM can be implemented using compose and compose^odd as 
follows. Let v;, vj be the encoding of the states s it sj respectively. Similarly, let 
v t> v t ^ e tne encoding of s tf s' t respectively. 

S^O + ttvj.vt) := SIMj (vj, V(.) A 

-icompoA*e-^/t/(ft(vj, vj), -^compose .odd (R t (v t , v' t ), S/Mj (vj, vj.))) 
/2eac/i5/M J + L (v|,v^) := ReachSIMj ;(vj, vj.) V 

(compo5e(compo5e(/2eac/i5/M i (v i ,v t ), /^(v; , vj)), fl e (v t , v' fc )) A S/M(vj , v' t )) 

The derivation of these expressions can be found in Appendix C. The algorithms 
above require that the implementation and specification "step" together along 
the transition relation. We break this to stepping along one, followed by step- 
ping along the other. This is possible since transitions of the two structures are 
independent. 

The comparison criteria Unimplemented Transition and Many To One can 
also be implemented with these operations. The two other criteria are defined 
over 2n variables and do not require such manipulation. 

UnirnplernentedTransition(v£ , v'f.) := R t (v£, vj.) A 

cornpose(compose(-<Ri (vj, vj), ReachSIM(v lt \r^)) } ReachSIM(v^ y vj.)) 
ManyToOne{v^) :— 

3v± (ReachSIM (v 1 , v t ) A compose^v^ £ v 2 ), ReachSIM(v 2 , v t ))) 

The details of these derivations can be found in Appendix C. 

Up to now we showed how to reduce the number of OBDD variables from An 
to 3n. We now show how to further reduce this number to 2n. Our first step is 
to use the same OBDD variables to represent the implementation variables vj 
and the specification variables v^-. These OBDD variables will be referred to as 
untagged. Similarly, we use the same OBDD variables to represent vj and vj.. 
They will be referred to as tagged OBDD variables. 

We also specify that whenever we have relations over both implementation 
variables and specification variables then the implementation variables are rep- 
resented by untagged OBDD variables while the specification variables are rep- 
resented by tagged OBDD variables. Note that now the relations Ri, R t} SIM, 
ReachSIM are all defined over the same sets of OBDD variables. Consequently, 
in all the derived expressions we apply compose and compose-odd to OBDDs 
that share variables, i.e. y and u are represented by the same OBDD variables. 
The implementation of compose and compose.odd uses non-standard OBDD op- 
erations in such a way that the resulting OBDDs are also defined over the same 
2n variables. 

Notice that this requires that the OBDD variable change semantics in the 
result (e.g., in Equation 1 y is represented by tagged OBDD variables in the 
input parameters and by untagged variables in the result). OBDD packages can 
easily be extended with these operations. 
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6 Reduced Tableau and Redundancies in Specification 



6.1 Smaller tableau structure 

When striving for completeness, the size of tableau structures as defined in [3] is 
usually too large to be practical, and may be much larger than the state space of 
the given implementation. This is because the state space of such tableaux con- 
tain all combinations of subformulas of the specification formula. Such tableaux 
usually contain many redundant states, that can be removed while preserving 
the tableau properties. If not removed, these states may introduce evidences 
which are not of interest. 

Much of the redundancies can be eliminated if each state contains exactly the 
set of formulas required for satisfying the specification formula. Consider for ex- 
ample the ACTL formula AXAXp. Its set of subformulas is {AXAXp, AXp,p}. 
We desire a tableau structure in which each state contains only the set of subfor- 
mulas required to satisfy the formula. In this case, the initial state should satisfy 
AXAXp, its successor should satisfy AXp and its successor should satisfy p. In 
each of these states all unmentioned subformulas have a "don't care" value. Thus, 
one state of the reduced tableau represents many states. For instance, the initial 
state {AXAXp} represents four initial states in the traditional tableau [3]. In 
such examples we may get a linear size tableau instead of an exponential one. 

Following the above motivation, the reduced tableau will be defined over a 
3-value labeling for atomic propositions, i.e., for an atomic proposition p, a state 
may be labeled by either p, -«p or neither of them. Also, only the reachable 
portion of the structure will be constructed. 

Further reduction may be obtained if the set of successors for each state is 
constructed more carefully. If a state $ has two successors s' and s", such that 
the set of formulas of s" is contained in the set of formulas of s', then s' is not 
constructed. Any tableau behavior starting at s* has a corresponding behavior 
from s" . Thus, it is unnecessary to include both. 

Given an ACTL safety formulas, the definition of the reduced tableau is 
derived from the Particle tableau for LTL, presented in [6] by replacing the use 
of the X temporal operator by AX. Since the only difference between LTL and 
ACTL is that temporal operators are always preceded by the universal path 
quantifier, this change is sufficient. In general, we will obtain a smaller tableau 
since we also avoid the construction of redundant successors. 

Since the reduced tableau is based on the 3-value labeling, the definition 
of satisfaction and simulation preorder are changed accordingly. Our reduced 
tableau T{tp) for ACTL then has the same properties as the one in [3]: 

- T(V0 N 

- For every Kripke structure M, M < T(rp) if and only if M (= ip. 

Note that adopting the reduced tableau also requires modifications to our criteria 
due to the 3-value labeling semantics. 



6.2 Reduced Tableau Results 

We have defined the reduced tableau and proved its tableau properties. In addi- 
tion we have adapted the comparison criteria to comply with the 3-value label- 
ing. We also coded the reduced tableau construction and the comparison criteria 
into the SMV model checker, performing the structure comparison in a symbolic 
manner. 

We have run the arbiter example of Section 4 with the reduced tableau. For 
the complete specification formula 0 presented there we received a structure 
with 20 states. A traditional tableau structure would have a state space of 2 15 
states for 0. 

6.3 Identifying redundancies in the specification 

Section 3 defines criteria that characterize when a specification is rich enough 
(i.e., complete). We would like also to determine whether a complete specification 
contains redundancies, i.e., subformulas that can be removed or be rewritten 
without destroying the completeness of the specification. 

Given the reduced tableau, we suggest a new criterion, called One To Many, 
that identifies implementation states that are mapped (by ReachSI M) to mul- 
tiple tableau states. Finding such states means that there is a smaller structure 
that corresponds to an equivalent specification formula. The criterion OneToMany 
is defined by: 

OneToMany — {s { € S t - | 3s Ut s 2t 6 5,[(s t J s u ) € ReachSIM A 
s 2 t) € ReachSIM A s u ^ $2*]}. 

6.4 One To Many Example 

The following example demonstrates the One to Many criterion. It identifies a 
redundant sub formula, which does not add to the completeness of the specifi- 
cation formula. Consider the following specification formula : 
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Our method reported that for tpone2Man y criteria 1-4 are met. In addition, 
it reported that the One To Many criterion is not met. As an evidence it pro- 
vides the implementation state 5,- such that Li(si) = {reqO, reql , ->ackO, ackl}. 
This state is mapped to su and S2t of the reduced tableau for which L t (su) — 
{reqO, reql, ->ackQ } ackl} and L t (s 2 t) = {reql, ->ackQ, ackl}. 
We may note that ^redundant sub formulas agrees with (ps for states labeled with 
{reqQ,reql}, and does not agree with <p 4 for states labeled with {^reqQ, req 1}. 
Since it comes as a disjunct, it does not limit the reachable simulation, and does 
not add allowed behavior. Deleting sub formula <prsdundant leaves a specification 
formula such that criteria 1-4 are met and the One to Many criterion is also 
met. 



7 Future work 

In this paper we presented a novel approach for evaluating the quality of the 
model checking process. The method we described can give an engineer the 
confidence that the model is indeed "bug-free" and reduce the development time. 

We are aware that the work we have done is not complete. There are a few 
technical issues that will have to be addressed: 

1. State explosion: The state explosion problem is even more acute than with 
model checking because we have to perform symbolic computations while M 
and T(tp) are both in memory. This implies that at present the circuits that 
we can apply this method to are smaller than those that we can model check. 
Therefore we currently cannot provide a solution for large models. However 
we believe that over time optimizations in this area will be introduced as 
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A Proof of Lemma 1 

Lemma 1 ReachSIM is a simulation preorder from M to M f . 

Proof. Clearly, for initial states, (s 0 , s' Q ) € SIM if and only if (s 0j s' 0 ) g ReachSIM 
Thus, for every initial state of M there is a /?eac/tS/M-related initial state of 
M'. Let (5,5') € ReachSIM. First we note that since ReachSIM C SIM, 
(s, s') e SIM and therefore L(s) = L'{s'). 

Now let (5,$i) e R- Then there is s{ such that (s',si) E R' and ($i,si) 6 
SIM. Since (5, s 7 ) £ ReachSIM , there are corresponding paths ir and tr 1 leading 
to s and s y . These paths can be extended to corresponding paths leading to Si 
and si. Thus, (s Xi s[) € ReachSIM. O 

B Proof of Theorem 2 

Theorem 1 Let M be an implementation model and $> be an ACTL safety 
formula such that M (= ip. Let T(ip) be a tableau for $ that satisfy the tableau 
properties. If the comparison criteria 1-3 hold then T(tp) < M. 

Proof Since M |= ip, M < T(tp). Thus, there is a simulation preorder SIM C 
Si x 5 t . Let ReachSIM be the reachable simulation preorder for SIM. Then 
ReachSIM' 1 C S t x Si is defined by (s t9 Si) € ReachSIM- 1 if and only if 
(si f s t ) € ReachSIM. We show that ReachSIM' 1 is a simulation preorder 
from T{$) to M. 



was done for model checking. We are investigating the possibility of running 
this method separately on small properties and then combining the results. 
Another solution to the state explosion is to compute the criteria M on-the- 
fly" together with the computation of ReachSIM and to discover violations 
before ReachSIM is fully computed. 

A third solution is to use the algorithm in [5] as a preliminary step, and try 
to expand it to fully support our methodology. The definition of Unimple- 
mented State is closely related to the evidences in [5]. On the other hand, our 
Unimplemented Transition criterion provides path evidences, while path cov- 
erage is not addressed by the methodology of [5]. Furthermore, our method 
can indicate that the specification and the implementation totally agree. 
This may serve as an indication that the verification process can be stopped. 

2. Irrelevant information: Similar to the area of traditional simulation cov- 
erage, measurement of quality produces a lot of information which is often 
irrelevant. A major problem is that specifications tend to be incomplete by 
nature and therefore we do not necessarily want to achieve a bisimulation 
relation between the specification and implementation. Therefore, it will 
eventually be necessary to devise techniques to filter the results such that 
only the interesting evidences are reported. 

We are also investigating whether the reduced tableau described in Section 6 
is optimal in the sense that it does not contain any redundancies. 

3. Expressivity: Our specification language is currently restricted to ACTL 
safety formulas. It is straight forward to extend our method to full ACTL. 
This will require, however, to add fairness constraints to the tableau struc- 
ture and to use the fair simulation preorder [3]. Unfortunately, there is no 
efficient algorithm to implement fair simulation [4]. Thus, it is currently im- 
practical to use full ACTL. There is a need to find logics that are both 
reasonable in terms of their expressivity and practical in terms of tableau 
construction and comparison criteria. 

Acknowledgment: We thank Ilan Beer for suggesting to look into the problem 
of coverage in model checking. The first author thanks Galileo Technology for 
the opportunity to work on the subject. 
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Let s l)t be an initial state of T(0). Since UnlmplementedS 'tart State is empty, 
there must be an initial state s oi of M such that ($oi.*ot) € ReachSfM, Thus,' 
(■»ot,*oi) € ReachSfM' 1 . 

Now let (s ft s,) 6 ReachSfM' 1 . Since (s t - ( s e ) 6 ReachSfM, L t {s t ) = Li(si). 
Let (st,s{) G Since UnimplementedState is empty, there must be a state s- G 
Si such that (a- € ReachSfM. Since UnlmplernenteclTransition is empty 
we get (s,-, s<) G Thus, s< is a successor of $ t and (s^s^) 6 ReachSfM- 1 . 
We conclude that ReachSfM' 1 is a simulation preorder and therefore T(^) < 
M. a 

Note that, since ReachSfM and ReachSfM 1 are both simulation preorders, 
ReachSfM is actually a bisimulation relation. 

C Derivation of the compose formulas 

Following is the algebraic derivation that enables the use of the compose and 
compose -odd operations described in Section 5. 

— Derivation of SfMj : 
S/A/,- +l (v i( v t ) '= 

Vv<[i?,(vi, vj) -+ 3v{. [ft(v t( v' t ) A SrMj(v' v v' t )]] A S/Af; (v- , v t ) = 
Vvjh^fvi.vpvav^^vt.viJAS/Af^vJ.vi)]] A S/M, (vj, v t ) = 
-3v^(v i)V i) A-3v£[/fc(v t ,v' t ) AS/M,^,^)]] A S/^Xv-.vt) = 
-.compose-odc^/i^v^ vj), -.compc?5e_ocf(f(^(v t , vj.), SIMj(vi , vj.))) A 5/iVf,- (vj, v 

— Derivation of ReachSIMj : 
/i + i(v t ,vj) := 

Iv^ReachSIMj^^ v t )ARi(v> v vj)) = compose(ReachSIMj (vj, v t ), ft(vj, vi)) 
»+i( v i« v t) := 

3 v t ( + 1 ( v t , v j ) A ( v t , v J. ) ) = compose ( + x ( v t , v j ) , R t ( v t , v' t ) ) 
£j+i( v i> v t) : = <7>+i(vj, v£) 

flcacAS/Af i+ i(vj, v t ) := (^-^(v;, v t ) ASIM^ , v t )) VReachSTMj (vj, v t ) 

— Derivation of ManyToOne: 
ManyToOne{v^) := 

3v l5 v 2 (ReachSIM(vi , v t ) A ReachSIMj » v t) A ( v l v 2)) = 
3v 1 (i2eac/i5/M(v 1 , v t ) A 3v 2 ((v 2 ^ v 2 ) A ReachSIM{v 2 , v t ))) = 
3v 1 (72eac/i5/M(v 1 , v t ) A compose^! ^ v 2 ), ReachSIM{^2 > v t))) 

— Derivation of UnimplementedTransition: 
/(v*,v t ):= 

3vj (-./? t (vj , vj)A.Reac/i5/yV/(v i , v t )) = compose (vj , vj) , ReachSIM{v- x , v t )) 
^( v t> v ' t ) : = 

3vj(/(v| f v t )Ai?cac/iS/Af(vi, v' fc )) = composc(/(vj , v t ), /2cacA5/Af(vj, vj.)) 
UnimplementedTransition{v^, vj.) := 5(v tt vJ.) A^(v t) vj.) 
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CLAIMS 

1 1* A method for verification, comprising: 

2 providing an implementation model, which defines 

3 model states of a target system and model transitions 

4 between the model states; 

5 providing a specification of the target system, 

6 comprising properties that the system is expected to 

7 obey; 

8 creating a tableau from the - specification, the 

9 tableau defining tableau states with tableau 

10 transitions between the tableau states in accordance 

11 with the properties; and 

12 comparing the tableau transitions to the model 

13 transitions to determine whether a discrepancy exists 

14 therebetween. 

1 2. A method according to claim 1, wherein creating 

2 the tableau comprises defining a finite state machine 

3 using a hardware description language. 

1 3. A method according to claim 2, wherein the 

2 implementation model has model inputs and outputs, and 

3 wherein defining the finite state machine comprises 

4 describing a virtual device having inputs and outputs 

5 corresponding to the model inputs and outputs of the 

6 implementation model. 

1 4. A method according to claim 3, wherein comparing 

2 the transitions comprises performing a reachability 

3 analysis using both the implementation model and the 

4 tableau while providing identical inputs to the inputs 

5 of both the implementation model and the tableau, and 

6 verifying that the outputs are always identical. 
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1 5. A method according to claim 4, wherein performing 

2 the reachability analysis comprises comparing the model- 

3 and the tableau automatically using a model checker. 

1 6. A method according to claim 4, wherein performing 

2 the reachability analysis comprises providing evidence 

3 of a tableau transition that is' not implemented in the 

4 model . 

1 7. A method according to claim 1, wherein comparing 

2 the tableau transitions comprises associating model 

3 transitions with corresponding tableau transitions. 

1 8, A method according to claim 7, wherein associating 

' 2 the transitions comprises defining a reachable 

3 simulation preorder relating the model and the tableau. 

1 9. A method according to claim 7, wherein associating 

2 the transitions comprises finding a tableau transition 

3 ' that is not implemented in the model. 

1 10. A method according to claim 9, wherein finding the 

2 tableau transition that is not implemented in the model 

3 comprises deriving an indication, based on the 

4 unimplemented transition, that the specification is not 

5 complete with respect to the model. 

1 11. A method according to claim 9, wherein finding the 

2 tableau transition that is not implemented in the model 

3 comprises deriving an indication, based on the 

4 unimplemented transition, that a transition of the 

5 target system is missing in the model. 

1 12. A method according to claim 1, and comprising 

2 associating model states with corresponding tableau 

3 states. 
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1 13. A method according to claim 12, wherein 

2 associating the model states with the corresponding 

3 tableau states comprises finding a tableau state that 

4 is not implemented in the model. 

1 14. A method according to claim 13, wherein finding 

2 the tableau state that is not implemented in the model 
3- • comprises deriving an indication, based on the 

4 urilmplemented state, that the specification is not 

5 complete with respect to the model. 

1 15. A method according to claim 13, wherein finding 

2 the tableau state that is not implemented in the model 

3 comprises deriving an indication, based on the 

4 unimplemented state, that a state of the target system 

5 is missing in the model . 

1 16. A method according to claim 12, wherein 

2 associating the model states with the corresponding 

3 tableau states comprises finding multiple model states 

4 corresponding to a single tableau state. 

1 17. A method according to claim 1, wherein creating 

2 the tableau comprises creating a reduced tableau from 

3 which one or more redundant states have been 

4 eliminated. 

1 18. A method according to claim 1, wherein comparing 

2 the transitions comprises verifying that the 

3 specification is a complete and correct description of 

4 the implementation model responsive to the comparison. 

1 19. A verification processor, which is configured to 

2 receive an implementation model, defining model states 

3 of a target- system and model transitions between the 

4 model states, and to receive a specification of the 

5 target system, including properties that the system is 
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6 expected to obey, and which is operative to create a 

7 tableau from the specification, the tableau defining 

8 tableau states with tableau transitions between the 

9 tableau states in accordance with the properties, and 

10 to compare the tableau transitions to the model 

11 transitions to determine whether a discrepancy exists 

12 therebetween, 

1 20. A processor according to claim 19, which is 

2 operative to perform model .checking of the 

3 implementation model. 

1 21. A computer software product for verification of a 

2 specification of a target system, which specification 

3 includes properties that the system is expected to 

4 obey, by comparison with an implementation model, which 

5 defines model states of the target system and model 

6 transitions between the model states, the product 

7 comprising a computer-readable medium having computer 

8 program instructions recorded therein, which 

9 instructions, when read by a computer, cause the 

10 computer to create a tableau from the specification, 

11 the tableau defining tableau states with tableau 

12 transitions between the tableau states in accordance 

13 with the properties, and to compare the tableau 

14 transitions to the model transitions to determine 

15 whether a discrepancy exists therebetween. 

1 22. A product according to claim 21, wherein the 

2 program instructions cause the computer to compare the 

3 tableau with the model by running a reachability 

4 analysis using both the implementation model and the 

5 tableau while providing identical inputs to the inputs 

6 of both the implementation model and the tableau, and 

7 verifying that the outputs are always identical. 

IS999-035 60 1 
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1 23. A product according to claim 22, wherein the 

2 reachability analysis is performed using an automatic 

3 model checker . 

1 24. A product according to claim 21, wherein the 

2 instructions cause the computer to verify that the 

3 specification is a complete description of the 

4 implementation model. 

1 25. A method for verification, comprising: 

2 providing an implementation model, which defines 

3 model states of a target system and model transitions 

4 between the model states; 

5 providing a specification of the target system, 

6 comprising properties that the system is expected to 

7 obey; 

8 creating a tableau from the specification, the 

9 tableau defining tableau states with tableau 

10 transitions between the tableau states in accordance 

11 with the properties; and 

12 comparing the model and the tableau by inputting 

13 the model and the tableau to an automatic model 

14 checking program. 

1 26. A method according to claim 25, wherein creating 

2 the tableau comprises defining a finite state machine 

3 using a hardware description language. 

1 27. A method according to claim 26, wherein the input 

2 model has model inputs and outputs, and wherein 

3 defining the finite state machine comprises describing 

4 a virtual device having inputs and outputs 

5 corresponding to the model inputs and outputs of the 

6 implementation model. 
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1 28. A method according to claim 27, wherein comparing 

2 the model and the tableau comprises running the model 

3 checker while providing identical inputs to the inputs 

4 of both the implementation model and the tableau, and 

5 verifying that the outputs are always identical. 

1 29. A method according to claim 25, wherein comparing 

2 the model and the tableau comprises providing evidence 

3 of a transition or state in the tableau that is not 

4 implemented in the model. 

1 30. A method according to claim 29, wherein providing 

2 the evidence comprises providing a counter-example 

3 indicative of the unimplemented transition or state. 

1 31. Model checking apparatus, which is configured to 

2 receive an implementation model, defining model states 

3 of a target system and model transitions between the 

4 model states, and to receive a specification of the 

5 target system, including properties that the system is 

6 expected to obey, and which is operative to create a 

7 tableau from the specification,, the tableau defining 

8 tableau states with tableau transitions between- the 

9 tableau states in accordance with the properties, and 

10 to compare the tableau to the model by inputting -..the 

11 model and the tableau to an automatic model checking 

12 program. 

1 32. A computer software product for verification of a 

2 specification of a target system, which specification 

3 includes properties that the system is expected to 

4 obey, by comparison with an implementation model, which 

5 defines model states of the target system and model 

6 transitions between the model states, the product 

7 comprising a computer-readable medium having computer 
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8 program instructions recorded therein, which 

9 instructions, when read by a computer, cause the 

10 computer to create a tableau from the specification, 

11 the tableau defining tableau states with tableau 

12 transitions between the tableau states in accordance 

13 with the properties, and to compare the tableau to the 

14 model by inputting the model and the tableau to an 

15 automatic model checking program. 
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